System and methods for identification of peer entities

ABSTRACT

In an illustrative embodiment, systems and methods for automatically identifying peer organizations of a subject organization within a transactional platform identify peer organizations of the subject organization by accessing characteristic features and transactional features of the subject organization, providing a portion of the features to similarity analysis models, and obtaining, through executing the models, predicted peer organizations. The predicted peers may be presented to a user arranged in priority order with some peer features of the respective organization and a control for selecting the respective peer. The user may select a subset of the predicted peers for use in comparison metrics.

RELATED APPLICATIONS

This application is a continuation of and claims priority to U.S. patentapplication Ser. No. 16/789,140, entitled “System and Methods forIdentification of Peer Entities,” filed Feb. 12, 2020 which claimspriority to U.S. Provisional Patent Application Ser. No. 62/805,594,entitled “System and Methods for Identification of Peer Entities,” filedFeb. 14, 2019. This application is related to the following prior patentapplications directed to identifying related entities for benchmarkingpurposes: U.S. patent application Ser. No. 15/850,047, entitled “Systemsand Methods for Intelligent Prospect Identification Using OnlineResources and Neural Network Processing to Classify Organizations Basedon Published Materials,” filed Dec. 21, 2017 (now U.S. Pat. No.10,606,853), and U.S. patent application Ser. No. 15/286,405, entitled“Dashboard Interface, Platform, and Environment for Supporting ComplexTransactions and Deriving Insights Therefrom,” filed Oct. 5, 2016 (nowpublished as US2017/0024827). All above identified applications arehereby incorporated by reference in their entireties.

BACKGROUND

Peer benchmarking in transactional environments relies uponidentification of similar entities to the subject organization.Historically, peer organizations have been identified using a variety oftechniques. In a first example, peer metrics may correspond to aselection of top performers within the system or platform. Performancemay be determined based upon, in some examples, premium share, marketshare, or performance specific to a metric identified by or accessed bya user. However, this method may result in an apples to orangescomparison of large, well-positioned entities to a smaller, newer,and/or geographically distinct entity. In another example, organizationsmay be classified by a number of factors (e.g., industry, region, size,etc.) and peers may be selected based upon factor similarities. However,oftentimes organizations may be classified within a number ofindustries, a number of regions, or otherwise fail to submit to binaryclassification in light of one or more factors. Further, in some systemsthere may be errors in classification leading to missed correlationsbetween an entity and its true peer(s). In a further example, a user maysupply a number of competitors, by name, for use in presenting peercomparison data. The user may need to supply a threshold number, furtherto the example, to avoid the ability of the subscriber to identifycompetitor metrics as belonging to a particular competitor. The user, inthis circumstance, may arbitrarily select recognized names as opposed toentities truly similar to the requesting organization, for example,based upon a limited recognition of the organization's peers in themarketplace.

In each of the above examples, as explained, the most relevant peers tothe organization may be overlooked. Thus, the inventors identified aneed for an improved method and system for discovering and applying themost relevant peer organizations to a requesting entity based uponanalysis of commonalities between organizations across a broad number offactors.

SUMMARY OF ILLUSTRATIVE EMBODIMENTS

In one aspect, an automated method and system for discovering andapplying the most relevant peer organizations to a requesting entityincludes accessing data identifying and describing member organizationsof the platform, characterizing the requesting entity using a number offeatures relevant to the data, and applying one or more models to thedata to identify peer organizations to the requesting entity. Thefeatures, in some examples, can include industry, region, and/or productclassification(s). Additionally, in reference to the insurance industry,the features can include exposure and program structure. The models usesimilarity modeling to find the nearest neighbor or closest peer.Machine learning driven feedback modeling may be used to create featurevectors for each member organization of the platform and each potentialpeer organization.

In some implementations, the improved method and system benefits therequesting entity through diversification of peer candidates by breakingdown peer similarities into a number of discrete models. The models, insome examples, can include a product similarity model, an organizationstructure similarity model, a performance similarity model, and/or anindustry similarity model. The results of the method and system mayinclude a number of candidate peers selected from each model.

In some implementations, the requester can express a preference for oneor more models. For example, the user may identify or rank in importanceparticular features such as product or program structure. In oneexample, a portion of peers recommended through each model may beweighted based upon the user's identification of important features. Inanother example, peers recommended through a model aligned with theuser's prioritized features may be promoted within a list of results. Ina particular example, if the user is interested in identifying peerswith layered polices, then peers identified through a program structuresimilarity model may be prioritized within the results.

The forgoing general description of the illustrative implementations andthe following detailed description thereof are merely exemplary aspectsof the teachings of this disclosure and are not restrictive.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of the specification, illustrate one or more embodiments and,together with the description, explain these embodiments. Theaccompanying drawings have not necessarily been drawn to scale. Anyvalues dimensions illustrated in the accompanying graphs and figures arefor illustration purposes only and may or may not represent actual orpreferred values or dimensions. Where applicable, some or all featuresmay not be illustrated to assist in the description of underlyingfeatures. In the drawings:

FIG. 1A and FIG. 1B are system flow diagrams of an example system forpeer discovery using data correlations and learning algorithms;

FIG. 2A is a flow chart of an example method for identifying andproviding a set of peers for use in peer comparison metrics;

FIG. 2B is a flow chart of an example method for selecting the mostrelevant peers obtained through applying multiple peer discoveryalgorithms to platform data records of a transactional platform;

FIG. 3A is a screen shot of an example user interface for requestingidentification of peers for use in comparison metrics;

FIG. 3B is a screen shot of an example user interface for interactingwith a set of peers identified through applying one or more peerdiscovery algorithms to system data records;

FIG. 4 is a system flow diagram of an example system for developing andrefining peer discovery algorithms for identifying peers within atransactional platform using platform data records;

FIG. 5 is a block diagram of an example environment for managingtransactions involving providers, subscribers, and brokers of insuranceproducts;

FIG. 6 is a block diagram of an example computing device; and

FIG. 7 is a block diagram of an example networking environment.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

The description set forth below in connection with the appended drawingsis intended to be a description of various, illustrative embodiments ofthe disclosed subject matter. Specific features and functionalities aredescribed in connection with each illustrative embodiment; however, itwill be apparent to those skilled in the art that the disclosedembodiments may be practiced without each of those specific features andfunctionalities.

Reference throughout the specification to “one embodiment” or “anembodiment” means that a particular feature, structure, orcharacteristic described in connection with an embodiment is included inat least one embodiment of the subject matter disclosed. Thus, theappearance of the phrases “in one embodiment” or “in an embodiment” invarious places throughout the specification is not necessarily referringto the same embodiment. Further, the particular features, structures orcharacteristics may be combined in any suitable manner in one or moreembodiments. Further, it is intended that embodiments of the disclosedsubject matter cover modifications and variations thereof.

FIGS. 1A and 1B are system flow diagrams of an example system flow 100for peer discovery in a transactional platform using data correlationsand learning algorithms. A requestor using the system 100 may wish toconduct a comparison of performance metrics with the metrics ofadditional peer organizations. While a requestor may recognize certainentities as competitors, oftentimes an organization has an incompleteunderstanding of similar organizations appropriate for performancecomparisons. This may be especially true when an organization has justbegun working in a new line of business, expanding to a new geographicregion, and/or offering a new product type. Further, while anorganization may focus upon a small handful of key competitors, forprivacy reasons, a larger number of peers may need to be combined togenerate metrics which cannot be reverse-engineered to obtain detailsregarding a particular organization. Thus, the system flow 100 enablespeer discovery using a number of models or classification algorithmsdesigned to match characteristics and/or metrics 106 of the requestor(or requestor's client) with other organizations within thetransactional platform. Further, the system flow 100 automates theidentification and presentation of peer organizations on a scale that isnot capable of being achieved by manual methods.

In some implementations, the system flow 100 begins with receiving auser request 102 for peer comparison metrics. The request, in anillustrative example, may be received by an insurance broker for use inpreparing a comparison of product coverage of various peers of a targetclient. The request, in simplest form, identifies a client organization.The organization may be a member of the transactional platform. In thiscircumstance, the system flow 100 may obtain the client characteristicsand/or metrics 106 for use in identifying peer organizations frominternal records. If, instead, the client is not a member of thetransactional platform (e.g., a prospective client), the user may beprompted to enter information regarding the client organization. Theclient characteristics and/or metrics 106, in some examples, includebusiness-related information (e.g., industry, size, region, etc.) and/ortransaction-related information (e.g., performance within the platform,product, exposure values, etc.). In some examples, the clientcharacteristics and/or metrics 106 may include a client name, geographiclocation(s), product identifier(s), revenue data, size data (e.g.,number of employees), and/or industry(s) to populate the clientcharacteristics and/or metrics 106. In some embodiments, a portion ofthe client characteristics and/or metrics 106 may be automaticallyobtained through external data sources such as, in some examples,Bloomberg, D&B Hoovers, S&P Global, or NASDAQ. The user, in someimplementations, may be requested to confirm the client characteristicsand/or metrics 106.

In some embodiments, the requester is presented with the opportunity toidentify relative importance of at least a portion of the clientcharacteristics and/or metrics 106. For example, the requester may bepresented with user interface controls to graphically identify relativeweights to apply to a business-related model versus atransaction-related model. In some examples, if the requester does notindicate relative weights for the client characteristics and/or metrics106, the system may apply a set of default weights based on historicalinformation indicating weights previously applied by the client and/oraverage weights from organizations sharing one or more characteristicswith the requester. In other examples, the default weights may be equalto one another.

In some implementations, the client characteristics and/or metrics 106are provided to a model evaluation engine 104 to identify applicablemodels and to supply data sets 108 appropriate for the execution ofthose models. The model evaluation engine 104 may access model inputs112 a stored in a data repository to determine characteristics and/ormetrics appropriate to each model. In some examples, the modelevaluation engine 104 determines whether the identified characteristicsand/or metrics have been provided in the client characteristics and/ormetrics 106. In one example, the model evaluation engine 104 mayidentify a subset of models appropriate to the request submitted by theuser. Further to the example, not all models may be appropriatedepending upon the particular geographic region, product, or industryidentified within the user request. In another example, the modelevaluation engine 104 may identify a subset of models appropriate to theavailable client characteristics and/or metrics 106 (e.g., models havingadequate characteristics and/or metrics inputs provided in the clientcharacteristics and/or metrics 106 to appropriately match the client topeer organizations).

Further, in some embodiments, the model evaluation engine 104 validatesthe submitted characteristics and/or metrics for completeness and/orconsistency prior to making it available for execution by a model. Forexample, some data may be absent or missing, or the values supplied maybe outside specified boundaries for the type of data. For example, for anew member of the platform, some transaction-related data may be missingor insufficient for deriving some of the transaction-related metrics.

The requester, in some embodiments, is asked by the model evaluationengine 104 to supply information regarding one or more of the missing orotherwise invalid client characteristics and/or metrics. In anotherexample, if the client submitted by the requestor represents a varietyof industries and business lines, the requestor may be prompted tonarrow the request for peers, if desired, to a certain subset of therequester's overall business. In other embodiments, models areautomatically filtered out based upon lack of trustworthy and/orsufficient data.

For each of the models selected by the model evaluation engine 104, insome implementations, a separate set of client data 108 is provided to amodel execution engine 110 for executing that model. In someimplementations the sets of client data 108 may be grouped according tothe type of data used by a respective model. For example, the modelevaluation engine 104 may provide a first client data set 108 acontaining transactional-based metrics for execution by a first modelexecution engine 110 a executing a transactional model, and a secondclient data set 108 b containing business-related characteristics forexecution by a second model execution engine 110 b executing a businesssimilarities model.

In some embodiments, the model execution engine(s) 110 execute modelsusing model data 112 b and peer characteristics and/or metrics 114. Afirst model executed by a first model execution engine 110 a, in someimplementations, is based upon k-nearest neighbors (KNN) clustering. Forthe KNN model, a training set of data 112 b is used to produce resultsbased upon information the model knows (e.g., known peer characteristicsand/or metrics 114 related to peer organizations within thetransactional platform). In some implementations, a second modelexecuted by a second model execution engine 110 b is a Business LinesSimilarity (BLS) model designed to identify peers sharing similarproduct(s) in one or more similar industries (e.g., based upon peercharacteristics and/or metrics 114 representing business line data).Characteristics and/or metrics 114 contributing to the BLS model, insome examples, can include global industry, global product, exposurevariable and value. In some implementations, a third model executionengine 110 c executes a Program Structure Similarity (PSS) model.Characteristics and/or metrics 114 contributing to the PSS model, insome examples, include one or more trade types, such as basic co-insuredprograms or layered programs.

The model execution engine(s) 110, in some implementations, supply aseparate set of peer results 116 for each model executed. The peerresults 116 of the multiple models may have little to no overlap inidentified peers. For example, unlike the BLS model, the PSS model maypresent peers in industries unrelated to the client industry. Further,the program structure may be indicative of relative size of theorganizations, such that the PSS model is more likely to identifysimilarly sized peers to the client. Thus, application of multiplemodels may provide greater diversity in peer candidates to therequester. The strategic identification, by the system, of specificmodels for peer identification that may not be intuitive to a humanevaluator further improves system processing efficiency by applying suchmodels where the peer characteristics and/or metrics 114 for therespective model align with the client characteristics and/or metrics106 of the requester.

Each set of peer results 116, in some implementations, includes alisting of peers and a confidence rating for each identified peer. Theconfidence rating, for example, may provide a relative strength of matchbetween the client and the identified peer. The listing of peers, insome embodiments, includes a key for identifying each peer organizationwithin the transactional platform such that metrics related to the peermay be accessed at a later point. In other implementations, the peerresults 116 include characteristics and/or metrics 114 for use in peerbenchmarking. The peer results 116, in some implementations, are storedin a temporary storage region 118 for later application.

Turning to FIG. 1B, in some implementations, the peer results 116 areaccessed by a weighting and ranking engine 120 for combining into asingle set of results for presentation to the user. The weighting andranking engine 120, for example, may select the top X references fromeach of the sets of peer results 116 according to the confidenceratings. In one example, the weighting and ranking engine 120 may select50 total peers from the results of two models (e.g., peer results set116 a and peer results set 116 b).

If the requestor submitted a prioritization, in some implementations,the weighting and ranking engine 120 accesses priorities 122 inweighting the results of each model 116. As discussed above, forexample, the requestor may have graphically identified relative weightsto apply to a business-related model versus a transaction-related model.At this point, a larger number of results may be selected by theweighting and ranking engine 120 from the preferred model in comparisonto the less important model to the requestor. For example, if thebusiness-related model was deemed twice as important as thetransactional model, two thirds of the total results may be derived froma business-related model result set 116 a, and one third of the totalresults may be derived from a transactional-related model result set 116b.

In some implementations, the weighting and ranking engine 120 takes intoconsideration historical selections 122 made by the requestor. In theevent that the client is a historic member of the transactionalplatform, for example, the weighting and ranking engine 120 may promoteorganizations within the peer results sets 116 previously identified bythe requestor as being a peer of the client. Conversely, the weightingand ranking engine 120 may promote organizations within the peer resultssets 116 where the requestor (or another user) previously identified theclient as a peer of those organizations. The historical pairings ofpeers, for example, may be maintained by the transactional platform toaid in the requestor's future identification of peers.

In some implementations, after selecting the subset of results of eachof the peer result sets 116, the weighting and ranking engine 120 ranksthe results. For example, the confidence ratings may be used to rankpeers within the combined peer results. Further, in the event that anoverlap of a same peer occurred within two or more of the results sets116, the multiply-identified peer may be promoted as a strong candidatefor matching the client. The weighting and ranking engine 120 mayproduce a combined list of peer results 122.

In some implementations, a graphical user interface (GUI) engine 124accesses the combined peer results 122 for display to the requestor at aremote requestor display device 126. The GUI engine 124, for example,may access peer characteristics and/or metrics 114, to the extent theywere not included in the combined peer results 122, for presentation tothe requestor. The GUI Engine 124 may generate a user-interactivedisplay of peer results for selection of a final set of peers by therequestor. In an illustrative example, the combined peer results 122 mayinclude between 30 and 100 potential peers, and the requestor may narrowthe peer results through selection of at least five of the combined peerresults 122. The GUI display created by the GUI engine 124, for example,may require that the requestor select a minimum number of peers toobtain de-identified metrics for presentation at the remote device 126.

In other implementations, rather than obtaining final peer selections bythe requestor through the GUI engine 124, the weighting and rankingengine 120 may select the set of combined peer results 122 for automaticgeneration of peer comparison metrics by the GUI engine 124. Forexample, the GUI engine 124 may produce, based upon metrics identifiedwithin the initial request 102, a graphical user interface comparingtransactional metrics of the client to peer transactional metrics.

FIG. 2A is a flow chart of an example method 200 for identifying andproviding a set of peers for use in peer comparison metrics. The method200, for example, may be executed by elements of the system flow 100 ofFIGS. 1A and 1B.

In some implementations, the method 200 begins with receiving a requestfor peer comparison with a client organization (202). The request, forexample, may be submitted by a remote computing device in communicationwith a transactional platform. The user request, for example, may be theuser request 102 of FIG. 1A.

In some embodiments, the user request is submitted through a peerbenchmark analysis graphical user interface, such as a peer benchmarkanalysis screen shot 300 of FIG. 3A. Turning to FIG. 3A, a requestor hasentered client “CYBER SECURITY ORG.” 302. Additionally, the requestorhas selected product network/cyber/privacy liability 304.

Returning to FIG. 2A, in some implementations, characteristic featuresand/or transactional features of the client identified in the requestare accessed (204). The features, for example, may be derived frommember identification records and/or transactional records oftransactions performed by the member (e.g., metrics representingtransactions submitted over time by the client, representativetransactional data of the client's activities within the transactionalplatform, etc.). The features, in one example, may include the clientcharacteristics and/or metrics 106 of FIG. 1A. Turning to FIG. 3A, thefeatures and metrics may include revenues and sales data 306, number ofemployees 308, and/or exposure type 310.

Returning to FIG. 2A, in some implementations, client feature datarequired for a first peer identification model is determined (206). Eachpeer identification model, such as the models discussed in relation tothe model inputs 112 a and model data 112 b of FIG. 1A, may require aparticular set of input data for use in identifying peer organizationsto the client organization. Some models may be more business-related innature, while other models are more transactional-related in nature. Themodel evaluation engine 104 of FIG. 1A, for example, may determineclient feature data required for the model. The client feature data mayinclude business characteristics of the client organization as well astransactional metrics collected by the transactional platform. If theclient is a prospective client, the user may be queried to enterbusiness characteristics and transactional information for use inidentifying appropriate peers. For example, turning to FIG. 3A, aprospect control 312, when selected, may provide the requestor with theopportunity to provide characteristics and metrics regarding aprospective client.

Returning to FIG. 2A, in some implementations, if adequate informationis available (208), a feature set for the model is prepared (210). Forexample, inputs required for the model may be collected and formatted asone of the data sets 108 for providing to one of the model executionengines 110, as illustrated in FIG. 1A. The feature set may be collectedfrom multiple data bases, such as a user information data base and atransactional data base.

In some implementations, if the information available is inadequate tosupply inputs to the model (208), or after the feature set for the modelis prepared (210), it is determined whether there are additional models(212). As discussed in relation to FIG. 1A, multiple models may beanalyzed to produce potential peers of the client identified by therequestor. For each of these additional models, it may be determinedwhat client feature data elements are required for the particular peeridentification model (214) and, if such data is available (208), anadditional feature set may be prepared for such model (210).

In some implementations, once all of the models have been considered andeach feature set prepared (212), the models for which feature sets havebeen prepared are executed to identify peer entities (216). The modelexecution engine(s) 110 of FIG. 1A, for example, may be used to executethe models using the client data set(s) 108 and, if applicable, othermodel data 112 b. As described in relation to FIG. 1A, the models mayinclude a BLS model and a PSS model. The results of the execution of themodel(s) may be stored in a temporary storage region, such as thestorage region 118 of FIG. 1A.

In some embodiments, execution of one or more of the models involves ak-nearest neighbor (KNN) clustering algorithm using the features inputfor the model. When using a KNN clustering algorithm, the requestordescribes the client using a handful of features, and these features arearranged as a vector of its features. Each potential peer client,similarly, can be described as a vector using values of the samefeatures. Next, the peer organizations are selected based on similaritybetween the requestor client vector and each potential peer clientvector. In determining the distance, the KNN algorithm may use differentdistance metrics and/or magnitude metrics. In a particular example, acosine distance metric may be used to identify angular distance betweenthe Business Line similarity features of the requestor's client and thepeer clients, thus finding peers demonstrating similarity in behavior inrelation to the Business Line feature. In another example, policy datafeatures of the requestor's client and the peer clients may be comparedusing a magnitude of variance metric to identify closely related policydata between the requestor's client and one or more peers. In someembodiments, the potential peer vectors are pre-calculated (e.g., on aperiodic basis or as new data is added to the transactional platformrelevant to the features used in the vector). Data validity andconsistency may be assured and maintained, for example, throughcollecting the information in advance and from sources of qualified datarecords. Additionally, calculating the vector information in advance mayspeed processing when calculating results. In other embodiments, thepotential peer vectors are calculated in real time responsive to therequest for peer organizations. Real time calculation, for example, mayprovide the most accurate matches based upon up-to-date transactionalinformation while saving on storage space for storing the vectors.Therefore, these feature vectors that uniquely characterize clients andtheir peers allow the system to function more efficiently and provideimproved accuracy in insights provided to clients that manual humanmethods are unable to achieve.

In some embodiments, execution of a peer identification model involvesderiving a characterization of the client organization submitted by therequestor from publicly available information from external data sourcesto identify peer entities. Overlapping board members between corporateentities, for example, may be discovered through information publishedby Bloomberg, D&B Hoovers, S&P Global, or NASDAQ. In another example,the model may deploy web crawling bots to identify news articles namingthe requestor submitted client and identify organizations named withinthe same publication.

In some embodiments, the results obtained through each model arefiltered to identify the best results. In one example, each model isprogrammed to return a particular number of results, such as, in someexamples, twenty, thirty, fifty, seventy-five, or one hundred records.In another example, each model is programmed to return all resultshaving a confidence level above a certain threshold such as, in someexamples, sixty, seventy, seventy-five, eighty, or over ninety percentconfidence level. The confidence threshold level may vary based upon thecloseness approximation desired. For example, sixty percent may equateto somewhat similar (e.g., gathering a large number of potential peersincluding edge cases), eighty percent may equate to generally similar(e.g., useful in most circumstances), while ninety percent may equate tovery similar (e.g., supplying a stronger exactness in peer match butreducing the candidate pool accordingly). In a particular example, agiven model may be programmed to return at least a minimum threshold ofresults and up to a maximum threshold of results of a confidence levelof X % or above.

In some implementations, if two or more models were executed (218), theresults of the models are combined to obtain combined search results(220). For example, as discussed in relation to FIG. 1B, the sets ofresults 116 may be accessed from the storage region 118 and combined bythe weighting and ranking engine 120. In one example, the combinedresults may be filtered to identify any duplicate results. Any duplicateresults may be prioritized or given greater weight, for example, forhaving been identified multiple times.

If the requestor submitted prioritization information regarding theresults, such as relative weights to apply between businesscharacteristic based models versus transactional metric based models, insome embodiments, the results are combined to use the top X results ofone set of results and the top Y results of the other set of resultsaccording to the ranking, as described in greater detail in relation toFIG. 1B.

In some embodiments, historical selections by the requestor areconsidered in creating the final result set. For example, if therequestor (or, alternatively, a different requestor) previouslyrequested a peer comparison on behalf of the requested client, theselections made during the previous peer comparison(s) may be added toand/or promoted within the peer results list (e.g., the confidencerating of any such peer organization may be increased).

In some implementations, the combined results are arranged by priority(222). For example, the weighting and ranking engine 120 of FIG. 1B mayarrange the combined results according to the confidence levelsassociated with each potential peer. Where two or more peer resultsshare a same confidence level, in some embodiments, the results arearranged in alphabetical order. In other embodiments, peer resultssharing a same confidence level may be prioritized by other indicia suchas, in some examples, whether each result was obtain through thepreferred model type (e.g., business model versus metrics model),whether any of the results were identified by multiple models, and/orwhether any of the results share a key characteristic with therequestor-identified client (e.g., industry, geographic region, line ofbusiness, etc.) By dynamically adjusting the weights and/or applied tothe peer results from different peer identification in real-time basedon unique aspects of each client, the system is able to identify highlytailored subsets of peers in real-time that humans would be unable toidentify manually due to human bias and lack of intuition into themethods employed by the models to identify peers.

In some implementations, the results are returned to the requestor(224). For example, the results may be made available to a graphicaluser interface engine, such as the GUI engine 124 of FIG. 1B, forpresentation to the requestor. As shown in FIG. 3B, for example, ascreen shot 330 presents characteristics and features 332 of the client302. Characteristics of the client 302 include a region (country) 332 a,an industry 332 c, and a Standard Industrial Classification (SIC) code332 d. Features of the client's transactional history with the platforminclude a year 332b the client's insurance policy became effective, anexposure value 332 e, a premium value 332 f, a limit value 332 g, and adeductible value 332 h. Further, client features may include a dataquality (DQ) indicator 332 i representing the completeness and/orestimated accuracy of information supplied regarding the client 302.These same characteristics and features are mirrored in peercharacteristics and features 336 a through 336 i for each peer 334returned to the requestor for review.

As illustrated in FIG. 3B, in some implementations, the requestor isinstructed to select a minimum number 338 of peers 334 (e.g., five), forpreparation of benchmark metrics. In conducting the review andselection, the requestor may sort the peers 334 according to any of thecharacteristics and features 336. By default, the peers 334 may bearranged in order of confidence of match with the client 302.

Although illustrated as a particular series of steps, in otherembodiments, more or fewer steps may be included in the method 200. Forexample, prior to determining the client feature data required, themethod 200 may identify one or more types of models preferred by therequestor. For example, the requestor, in some implementations, may beprovided the ability to submit preferences toward transactional modelsversus business information models. In another example, upon determiningthe data is inadequate (e.g., data for one or more features is absent ormissing), the data may be approximated or corrected in some manner toprovide ample information for identifying peer organizations. Inparticular, in the circumstance of layered or tower pricing structures,competitors may have similar but mismatched structures (e.g., somelayers may be missing, other layers may not quite match up). Methods andsystems for addressing mismatching layer or tower pricing structures aredescribed in U.S. Ser. No. 15/852,260 entitled “Methods and Systems forPerforming Pricing Comparisons of Complex Layered or Tower PricingStructures with Varying Pricing Components” filed Dec. 22, 2017 andincorporated herein by reference in its entirety. In another example, insome implementations, rather than verifying availability of adequatedata, one or more models are programmed to automatically gather clientfeature data (e.g., access one or more data bases to obtain data recordsbased upon the identified client). In this circumstance, the output ofthe model, including the confidence in the accuracy of the matching ofeach peer organization, may be indicative of poor-quality data obtainedby the model.

Additionally, in some embodiments, some of the steps of the method 200may be performed in a different order or in parallel. For example, themodels may begin execution (216) while additional models are beingevaluated for available client feature data (214) to allow for parallelprocessing of a portion of the method 200. In another example, theresults of the models may be combined prior to filtering to the topresults. Other modifications may be made to the method 200 whileremaining in the spirit and scope of its functionality.

FIG. 2B is a flow chart of an example method 230 for selecting the mostrelevant peers obtained through applying multiple peer discoveryalgorithms to platform data records of a transactional platform. Themethod 230, for example, may be performed at least in part by theweighting and ranking engine 120 of FIG. 1B. The method 230, in someembodiments, describes certain details of the steps of combining resultsof two or more models (220) and arranging the results by priority (222)of the method 200 of FIG. 2A.

In some implementations, the method 230 begins with obtaining resultsfrom one or more peer identification models (232). For example, theresults may be obtained by the model execution engine(s) 110 of FIG. 1A.Obtaining the results, for example, may be performed as described inrelation to step 216 of FIG. 2A.

In some implementations, if the same entity is identified as a peer inmultiple result sets generated by two or more models (234), the repeatedentities are promoted as peer matches (236). The promotion, in someexamples, can include adding the repeated entity(s) to the top of thelist as the most likely candidate(s), increasing the confidence value ofthe repeated entity(s) by a threshold percentage (e.g., 10%, 20%, 50%,etc.), or increasing the confidence value of the repeated entity(s) by athreshold value (e.g., 10 points, 20 points, 50 points, etc.). Indetermining repeated entity(s), in some embodiments, the system analyzesidentified peers for matches based upon entity relationships. Forexample, a same entity may include a number of subsidiaries, such thattwo identified peers function under the same corporate structure. Forexample, U.S. Patent Pub. No. 2018/0181625 entitled “Systems and Methodsfor Intelligent Prospect Identification Using Online Resources andNeural Network Processing to Classify Organizations based on PublishedMaterials” describes systems and methods for resolving entityrelationships through name variants and corporate hierarchies, theentire contents of which is incorporated herein by reference.

In some implementations, the results in each set are prioritizedaccording to a likelihood of match (238). Using confidence valuesassociated with each of the entities, for example, the peers in eachlist of results may be organized according to likelihood of match. Theweighting and ranking engine 120 of FIG. 1B may perform theprioritization. The peer results, for example, may be arranged asdescribed in relation step 222 of FIG. 2A.

In some implementations, if a weighting preference was provided by therequestor (240), requestor weightings are identified for application tothe result sets (242). As discussed in relation to FIG. 1B, for example,the requestor may have graphically identified relative weights to applyto a business-related model versus a transaction-related model. Forexample, if the business-related model was deemed twice as important asthe transactional model, two thirds of the total results may be derivedfrom a business-related model result set, and one third of the totalresults may be derived from a transactional-related model result set. Inanother example, if the requestor or another user previously identifiedone or more of the potential peers as being a peer of the client, thoseentities may be promoted within the peer results.

If, instead, no weighting preference was provided (240), in someimplementations, equal weightings are used (244).

In some implementations, peers are selected from each set of results inaccordance with the weighting and the likelihood of match (246). Unlessrequestor weightings were identified (242), an equal number of resultsare selected from each of the result sets of each model executed.

In some implementations, the result set is prepared for presentation tothe requestor in a graphical user interface (248). For example, the GUIengine 124 may prepare the results for presentation at the userinterface 126, as described in relation to FIG. 1B. The graphical userinterface, for example, may be similar to the screen shot 330 of FIG.3B.

In some implementations, a filter control is selected by the requestorvia the user interface (250). Turning to FIG. 3B, in some embodiments,the requestor may filter the peers 334 by one or more of thecharacteristics and features 336. For example, each of the region 336 a,the year 336b, the industry 336 c, the exposure value 336 e, the premiumvalue 336 f, the limit value 336 g, the deductible value 336 h, and theDQ indicator 336 i is associated with a corresponding filter control 340to either specify a value range (e.g., 340 d, 340 e, 340 f, and 340 g)or to select specific characteristic and/or property information (e.g.,340 a, 340 b, 340 c, 340 h). In a particular example, the industry 336 cmay be limited to particular industries such as industry 332 c(technology . . . ), while the premium value 336 may be increased to avalue closer to the premium 332 f of 770 million, such as “at least 500million.”

If the filter control was selected, in some implementations, a filter isapplied to the result sets to obtain updated result sets (252). Forexample, upon filtering, in some implementations, the method 230 returnsto the results of the execution of the model(s) 238 to re-evaluate theresults in light of the filtered characteristics and/or featuressupplied by the requestor. Further, the results may be recombined (246)prior to returning updated results to the requestor (248). In someexamples, because of the use of the customized data structures used inexecution of the model(s) (e.g., client feature vectors, peer featurevectors), the method 230 can provide real-time adjustments to theresults in light of the provided filter inputs.

Although illustrated as a particular series of steps, in otherembodiments, more or fewer steps may be included in the method 230. Forexample, in other embodiments, filtering may involve filtering theoriginally supplied results (246) rather than returning to the originalcomplete set(s) of results (238).

Additionally, in some embodiments, some of the steps of the method 230may be performed in a different order or in parallel. For example, inother embodiments, the results may be prioritized after selecting fromeach result set (e.g., during combining step 246). Other modificationsmay be made to the method 200 while remaining in the spirit and scope ofits functionality.

FIG. 4 is a system flow diagram of an example process flow 400 fordeveloping and refining peer discovery algorithms for identifying peerswithin a transactional platform using platform data records. The processflow 400 may aid in model validation of the models executed by the modelexecution engine(s) 110 of FIG. 1A. Further, the process flow 400 mayaid in identifying features and/or characteristics most relevant todetermining peers (e.g., features and/or characteristics which may beincluded into a new peer identification model).

In some implementations, the process flow 400 begins with receiving arequestor's selections of peers of an identified client (402). Theselections, for example, may be obtained through the graphical userinterface screen shot 330 of FIG. 3B. For example, the selections may beobtained through the GUI engine 124 of FIG. 1B. The selections mayidentify a peer entity as well as, in some embodiments, identificationof a model through which the peer entity was identified. Further, theselections may each identify a confidence value attributed to theparticular peer entity. In some embodiments, the selections mayadditionally include interactions of the user with the graphical userinterface, such as selected filters and/or particular ranges orcategories applied to the initial results through interactions with thefilters.

In some implementations, the selected peers are supplied to one or moremodel validation engines 404 for validating the confidence ratingsapplied by each model. The model validation engine(s) 404, for example,may compare the model's top prioritized peer suggestions to therequestor's peer selections. The model validation engine(s) 404, in someembodiments, feed the requestor selections to model data 112 forlearning purposes, thereby improving the algorithm for future use. Theselections, in some embodiments, are each correlated with at least onepeer identification model. In this manner, the model validation engine404 associated with a particular model may apply those peers identifiedthrough that model as learning data for refining that model.

The model validation engine(s) 404, in some implementation, create oneor more model validation reports 406. The model validation reports mayprovide metrics regarding the overlap of highest confidence peers withthe requestor's selected peers. Further, if the requestor submittedadditional peers not identified by the model(s), the model validationreports 406 may supply metrics or other information regarding thepropensity for requestors to identify peers outside the suggested peers.Additionally, the model validation reports may include informationregarding common filters applied to results by the users prior to and/orduring the process of selecting peers.

To further refine the functionality of the peer identification models,in some implementations, one or more feature correlation engines 408 maycorrelate the features and characteristics of the requestor selectionswith features and characteristics of the client to identify patterns ortrends of similarities between the client and the selected peers. To theextent these features and characteristics are not provided with theselections 402, in some embodiments, the feature correlation engine(s)408 may access entity characteristics and/or metrics of both the clientand the selected peers to cross-reference similarities incharacteristics and features. A first feature correlation engine 408 mayidentify direct correlations, such as industry and region, while asecond correlation engine 408 may identify indirect correlations, suchas metrics within a certain range. The range, in one example, may beselected by the requestor through the filters, as described in relationto FIGS. 2B and 3B. Information regarding feature correlations evidencedin the requestor selections 412 may be provided by the featurecorrelation engine(s) 408 for use in building additional model(s). Thefunctions performed by the feature correlation engine(s) 408 furtherprovide a technical solution to a technical problem in that they areable to detect correlations between clients and peers that areundetectable to manual human methods at the processing rates achieved bythe system.

FIG. 5 illustrates a block diagram of an example environment 500 foridentifying peer relationships within an insurance exchange system 502.The environment 500 includes a number of providers (e.g., clients) 504,such as insurance providers, as well as a number of brokers 506, such asinsurance brokers. The clients 504 and brokers 506 may access theinsurance exchange system 502 using a variety of computing devices, asillustrated.

In some implementations, the insurance exchange system 502 includes adata repository 512 housing information for use by a number of engines516 through 538 of the insurance exchange system 502. The datarepository 512 may include one or more non-transitory computer readablemedium, for example within one or more database resources or other datarepositories of the environment 500.

The insurance exchange system 502, in some implementations, includes aclient management engine 516 for managing client information. The clientmanagement engine 516, for example, may collect and scorecharacteristics regarding clients of the insurance exchange system 502(e.g., clients that have purchased products through one or more of thebrokers 506). Further, in some implementations, the client managementengine 516 may obtain and store metrics regarding clients 516, such asclaims metrics or relationship metrics with the brokers 506 and/orproviders 504. The metrics, for example, may be calculated by one ormore metrics generation engine(s) 536. In some examples, the metrics mayinclude products purchased by each client (e.g., identified by productdata 540 and/or plan data 546) including exposure, premium, limit, anddeductible of a layered or tiered product. The metrics may furtherinclude metrics derived through insurance claims submitted through theinsurance exchange system 502 (e.g., as received through one or moretransaction processing engines 534). The client management engine 516,for example, may manage subscriber data 542 stored in the datarepository 512.

In some implementations, the insurance exchange system 502 includes abroker management engine 518 for managing broker information on behalfof the brokers 506, such as the broker data 550 of the data repository512 and the peer selections data 560. The broker data 506, for example,may include characteristics and login information regarding the brokers506. The peer selections data 560 may include an audit history ofselections each broker 506 made in identifying peer enterprises to aparticular client (e.g., subscriber identified via subscriber data 542).The peer selections data 560, for example, may be gathered by a GUIengine 532 in obtaining user inputs from brokers 506 via the userinterface 330 of FIG. 3B.

The insurance exchange system 502, in some implementations, includes oneor more model evaluation engine(s) 520 for evaluating known informationregarding a client and matching that information with one or moreappropriate models for peer identification. The model evaluationengine(s) 520 may identify availability of client characteristics, forexample obtained through the subscriber data 542 and/or the GUI engine532 (e.g., submitted by one of the brokers 506 in relation to therequest for peer analytics), matching model input data 554 of the datarepository 512 required by one or more model execution engine(s) 522.Further, the model evaluation engine(s) 520 may identify availability ofclient metrics, for example obtained through transaction metrics data556 of the data repository 512 and/or otherwise generated by metricsgeneration engine(s), matching model input data 554 required by one ormore model execution engine(s) 522. In some embodiments, a one-to-onematching exists between the model evaluation engine(s) 520 and the modelexecution engine(s) 522, such that a given model evaluation engine 520executes as a precursor to launching the corresponding model executionengine 522 to identify peers to the identified client. The modelevaluation engine(s) 520, for example, may execute a portion of theprocess 100 of FIG. 1A (e.g., related to the model evaluation engine104) and/or the method 200 of FIG. 2A. The output of the one or moremodel evaluation engine(s) 520 may include one or more client data setscontaining client characteristics and/or metrics for use as input datato the model execution engine(s) 522. One or more client data sets 564output by the model evaluation engine(s) 520, for example, may be storedin a computer readable media 562 for access by other engines of theinsurance exchange system 502, such as the model execution engine(s)522. In some examples, for each requestor, the model evaluation engine520 generates a client data set for each of the models where each dataset is customized to the respective model and includes features that areuniquely associated to the particular model.

In some implementations, the insurance exchange system 502 includes theone or more model execution engines 522 for performing peer analysisregarding a client. The model execution engine(s) 522 may be designed toidentify peer enterprises to a client enterprise based uponcharacteristics obtained through the subscriber data 542 and/or the GUIengine 532. Further, the model execution engine(s) 522 may be designedto identify peer enterprises to a client enterprise based upontransaction metrics 556 related to subscribers. The model executionengine(s) 522 may each accept, for example, certain model inputs (e.g.,subscriber characteristics and/or metrics) identified by the modelevaluation engine(s) 520. The model execution engine(s) 522 may applymodel data 548 (e.g., training data) in developing one or more models toaccurately identify peers of a subscriber based upon the characteristicsand/or metrics. The model execution engine(s) 522, for example, mayexecute at least a portion of the process 100 of FIG. 1A (e.g., that ofthe model execution engine(s) 110) and/or the method 200 of FIG. 2A.Each model may provide a set of peer results 566 to the computerreadable media 562 for access by other engines of the insurance exchangesystem 502, such as a weighting and ranking engine 524.

In some implementations, the weighting and ranking engine 524 obtainsidentified peers from the model execution engine(s) 522, combines theoutputs from the multiple model execution engines 522 if two or moremodels were used, and arranges the results in a priority order. Indetermining prioritization of the results, in some embodiments, theweighting and ranking engine 524 accesses peer selections data 560 ofthe data repository 512 to identify whether an archive of previouslyidentified peers of the subject client is available. For example,organizations previously identified as peers of the client may bepromoted by the weighting and ranking engine 524. The weighting andranking engine 524, for example, may perform at least a portion of theprocess 100 of FIG. 1B (e.g., related to the weighting and rankingengine 120). The weighting and ranking engine 524, for example, mayperform at least a portion of the method 230 of FIG. 2B. Combined peerresults 568 created by the weighting and ranking engine 524, in someembodiments, are placed in the computer readable media 562 for access byother engines of the insurance exchange system, such as a graphical userinterface (GUI) engine 532.

The GUI engine 532, in some implementations, receives a request from oneof the brokers 506 for peer comparison metrics for an identified clientand responds with presenting peer results for broker review. In otherimplementations where selection of the set of peers is fully automated,the GUI engine 532 responds to the broker's request for peer metricswith a presentation of comparison metrics. The request for peer metricsmay be placed via a user interface previously supplied by the GUI engine532 to the broker 506 via a network. At least a portion of the brokers506 may communicate with the insurance exchange system 502 through a webinterface such as a web browser such that the request is providedthrough the browser interface. At least a portion of the brokers 506interface with the insurance exchange system 502 via a network portal,for example using a software package provided by the insurance exchangesystem, such that the request is provided through the portal connectionto the insurance exchange system 502.

If the identified client has purchased one or more products 540 throughthe insurance exchange system 502, the subscriber data 542 may containcharacteristics of the client. Otherwise, in the event that the clientis a prospective client identified by the broker 506, the broker 506 mayenter information regarding the client through a user interface providedby the GUI engine 532 (e.g., such as the user interface 300 of FIG. 3,through selection of the prospect control 312). In further embodiments,a query engine (not shown) may access prospective client informationfrom one or more databases of corporate statistics (e.g., locallycollected or accessed on the fly through a web query to a web sitehosting such information). The characteristics, in some examples, mayinclude size (e.g., number of employees), financial position (e.g.,market share, gross operating profit (GOP), sales volume, etc.), region(e.g., country, province, state, city, etc.), industry, and/or maturity(e.g., years since incorporation).

The GUI engine 532, in some embodiments, supplies the requestinformation to the model evaluation engine 520 to initiate the internalpeer identification process of the insurance exchange system 502. Ifsubmitted by the broker 506 through the GUI engine 532, the GUI engine532 may further supply at least a portion of the client characteristics.

In implementations where peer results are presented for broker review,the GUI engine 532 may receive combined peer results 568, for example asgenerated by the weighting and ranking engine 524. The GUI engine 532may prepare a user interface listing the combined peer results 568 forpresentation to the broker 506 (e.g., through the web browser or portalas discussed above). The user interface, for example, may be the userinterface 330 of FIG. 3B. The user interface provided by the GUI engine532 may identify each peer along with a number of peer characteristicsand/or metrics. Further, the user interface may allow the broker 506 tosort and/or filter the information based upon each of thecharacteristics and/or metrics. By default, in an illustrative example,the peers may be presented in the priority order identified by theweighting and ranking engine 524.

In some implementations, the GUI engine 532 further receives brokerselections of a portion of the identified peers. The broker selections,for example, may be added to the peer selections data 560 for later use.In some embodiments, the broker selections are stored along with atleast a portion of the present characteristics and/or metrics of eachpeer organization. For example, peers may be identified based uponcharacteristics and/or metrics that may change over time, such that apeer may be less relevant in the future. As such, peer selections data560 may be linked to present characteristics and/or metrics so that oneor more model validation engines 404 may analyze the information toidentify trends in the characteristics and/or metrics which appear tolead to selection.

In some implementations, the GUI engine 532 supplies the broker selectedpeers to one or more of the metrics generation engines 536. Using theselected peers, for example, the metrics generation engine(s) 536 maydiscern aggregate metrics regarding the peers. For example, the set ofpeers selected by the broker 506 may be de-identified through combiningthe individual metrics into a representative “peer metric” for each of anumber of metric data values. The aggregate metrics may be presented tothe user through a subsequent user interface presentation generated bythe GUI engine 532.

In some implementations, the model validation engine(s) 530 analyze thepeer selections made by the broker 506 to validate the ranking and/orrating of the peers within each model's set of peer results (e.g., asapplied by the model execution engines 522). Each model validationengine 530 may correspond with a particular model execution engine 522.The peer selections, as discussed above, may be stored as peerselections data 560 for later validation. In some embodiments, the modelvalidation engine(s) 530 are executed periodically upon accumulated peerselections data 560 to gauge effectiveness of each model in identifyingappropriate peer organizations. For example, the model validationengine(s) may be executed on a scheduled basis (e.g., every week, everymonth, etc.), on a volume basis (e.g., after X number of records of peerselection data have been collected or after Y requests by the brokers506 for peer identification). The model validation engine(s) 530 maydetermine one or more metrics to compare the peer predictions with peerselections made by users, including user-entered peers not proposedwithin the predicted peers. Percentile match predicted for each selectedpeer, for example, may be analyzed to confirm relevancy of theprediction algorithm(s). The metrics, in some examples, may include anaverage or mean deviation from anticipated match to actual matchresults, a percentage selection of peer results in a thresholdpercentile of peer results presented (e.g., top 10%, top quartile,etc.), and/or prevalence of selection of peer results from each of a setof percentile tiers of match confidences. The model validation engine(s)530 may perform one or more operations of the process 400 of FIG. 4,such as the operations of the model validation engine(s) 404. Themetrics generated by the model validation engine(s) 530, for example,may be stored as peer selection metrics 570 in the computer readablemedia 562 for sharing with other engines of the insurance exchangesystem 502, such as a report generation engine 538.

In some embodiments, where the peer selections data 560 includes one ormore peer additions of enterprises not identified within the peerresults presented to the broker 506, the model validation engine(s) 530may identify a commonality of additions to the peer selections outsideof the recommendations provided through application of one or moremodels. For example, the GUI engine 532 may include an entry field forentering a new peer in addition to selecting from the recommended peers.

In some embodiments where the brokers 506 are provided the opportunityto select between available models and/or to weight or otherwise promoteresults obtained through a particular model or model type, the modelvalidation engine(s) 530 may calculate metrics expressing propensity forselecting peers from the promoted model/model type versus selectingpeers from the demoted model/model type. For example, the peerselections data 560, in addition to containing peer identifications andweights applied to various models, may also include an indication ofwhether the model or model type was demoted (or another model of thesame time de-selected, etc.). In an illustrative example, the modelvalidation engine(s) 530 may calculate the percentage of selections madefrom results obtained from a promoted (in priority or weight) model ormodel type and percentage of selections made from results obtained froma demoted (in priority or weight) model or model type.

In some embodiments, the model validation engine(s) 530 generateadditional training data (e.g., derived from the peer selections data560) for training the model execution engine(s) 522. For example, themodel validation engine(s) 530 may supply training data to the modeldata 548.

In some implementations, the report generation engine 538 generates oneor more reports presenting the metrics generated by the model validationengine(s) 530. The report generation engine 538, for example, maycombine the peer selection metrics 570 into tables, graphs, and othercomparison illustrations to demonstrate performance of the various modelexecution engine(s) based upon the peer selections data 560. In someembodiments, the report generation engine 538 combines the peerselection metrics 570 with additional metrics, for example generated bythe metrics generation engine(s) 536. The additional metrics, in someexamples, may include frequency data of model selection of the variousmodels used by the model execution engine(s) 522, frequency data ofmodel weighting of the various models used by the model executionengine(s) 522, and/or frequency data of peer entry by the brokers 506 ofpeer organizations not identified within the combined peer results 568.

In some implementations, a feature correlation engine 528 of theinsurance exchange system 502 analyzes the peer selections data 560 toidentify feature correlations (e.g., peer characteristics and/ormetrics) evidenced in the peer selections data 560. For example, thefeature correlation engine 528 may statistically analyze selections inlight of additional feature data (e.g., characteristics and/or metricsof the organizations identified within the peer selections data 560).The feature data, for example, may be derived from the subscriber data542 and/or transaction data 552 (e.g., as evidencing subscriber purchaseof products and/or plans identified within the product data 540, or plandata 546). In some embodiments, the feature data may be derived in partthrough accessing additional characteristics and/or metrics fromexternal sources. For example, the feature correlation engine 528 mayanalyze characteristics and/or metrics regarding at least a portion ofthe organizations identified within the peer selections data 560 frompublic sources such as business information web sites or data bases. Thefeature correlation engine 528, in some embodiments, proposes one ormore new groupings of characteristics and/or metrics for defining one ormore new models for addition to the insurance exchange system 502 asmodel execution engines 522.

Next, a hardware description of the computing device, mobile computingdevice, or server according to exemplary embodiments is described withreference to FIG. 6. The computing device, for example, may representthe providers 504, brokers 506 and/or computing systems of the insuranceexchange system 502 of FIG. 5. In FIG. 6, the computing device, mobilecomputing device, or server includes a CPU 600 which performs theprocesses described above. The process data and instructions may bestored in memory 602. The processing circuitry and stored instructionsmay enable the computing device to perform, in some examples, theoperational flow 100 of FIGS. 1A and 1B, the method 200 of FIG. 2A, themethod 230 of FIG. 2B, or the operational flow 400 of FIG. 4. Theseprocesses and instructions may also be stored on a storage medium disk604 such as a hard drive (HDD) or portable storage medium or may bestored remotely. Further, the claimed advancements are not limited bythe form of the computer-readable media on which the instructions of theinventive process are stored. For example, the instructions may bestored on CDs, DVDs, in FLASH memory, RAM, ROM, PROM, EPROM, EEPROM,hard disk or any other information processing device with which thecomputing device, mobile computing device, or server communicates, suchas a server or computer. The storage medium disk 604, in some examples,may store the contents of the storage 106, 112 a, 112 b, 114, and/or 118of FIG. 1A, storage 410 of FIG. 4, and/or data repository 512 orcomputer readable media 562 of FIG. 5.

Further, a portion of the claimed advancements may be provided as autility application, background daemon, or component of an operatingsystem, or combination thereof, executing in conjunction with CPU 600and an operating system such as Microsoft Windows 10, UNIX, Solaris,LINUX, Apple MAC-OS and other systems known to those skilled in the art.

CPU 600 may be a Xenon or Core processor from Intel of America or anOpteron processor from AMD of America, or may be other processor typesthat would be recognized by one of ordinary skill in the art.Alternatively, the CPU 600 may be implemented on an FPGA, ASIC, PLD orusing discrete logic circuits, as one of ordinary skill in the art wouldrecognize. Further, CPU 600 may be implemented as multiple processorscooperatively working in parallel to perform the instructions of theinventive processes described above.

The computing device, mobile computing device, or server in FIG. 6 alsoincludes a network controller 606, such as an Intel Ethernet PRO networkinterface card from Intel Corporation of America, for interfacing withnetwork 628. As can be appreciated, the network 628 can be a publicnetwork, such as the Internet, or a private network such as an LAN orWAN network, or any combination thereof and can also include PSTN orISDN sub-networks. The network 628 can also be wired, such as anEthernet network, or can be wireless such as a cellular networkincluding EDGE, 3G, 4G, and 5G wireless cellular systems. The wirelessnetwork can also be Wi-Fi, Bluetooth, or any other wireless form ofcommunication that is known. The network 628, for example, may supportcommunications between insurance exchange system 502 and any of theproviders 504 and/or brokers 506 of FIG. 5.

The computing device, mobile computing device, or server furtherincludes a display controller 608, such as a NVIDIA GeForce GTX orQuadro graphics adaptor from NVIDIA Corporation of America forinterfacing with display 610, such as a Hewlett Packard HPL2445w LCDmonitor. A general purpose I/O interface 612 interfaces with a keyboardand/or mouse 614 as well as a touch screen panel 616 on or separate fromdisplay 610. General purpose I/O interface also connects to a variety ofperipherals 618 including printers and scanners, such as an OfficeJet orDeskJet from Hewlett Packard. The display controller 608 and display 610may enable presentation of the user interfaces illustrated, in someexamples, in FIGS. 3A and 3B.

A sound controller 620 is also provided in the computing device, mobilecomputing device, or server, such as Sound Blaster X-Fi Titanium fromCreative, to interface with speakers/microphone 622 thereby providingsounds and/or music.

The general purpose storage controller 624 connects the storage mediumdisk 604 with communication bus 626, which may be an ISA, EISA, VESA,PCI, or similar, for interconnecting all of the components of thecomputing device, mobile computing device, or server. A description ofthe general features and functionality of the display 610, keyboardand/or mouse 614, as well as the display controller 608, storagecontroller 624, network controller 606, sound controller 620, andgeneral purpose I/O interface 612 is omitted herein for brevity as thesefeatures are known.

One or more processors can be utilized to implement various functionsand/or algorithms described herein, unless explicitly stated otherwise.Additionally, any functions and/or algorithms described herein, unlessexplicitly stated otherwise, can be performed upon one or more virtualprocessors, for example on one or more physical computing systems suchas a computer farm or a cloud drive.

Reference has been made to flowchart illustrations and block diagrams ofmethods, systems and computer program products according toimplementations of this disclosure. Aspects thereof are implemented bycomputer program instructions. These computer program instructions maybe provided to a processor of a general purpose computer, specialpurpose computer, or other programmable data processing apparatus toproduce a machine, such that the instructions, which execute via theprocessor of the computer or other programmable data processingapparatus, create means for implementing the functions/acts specified inthe flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in acomputer-readable medium that can direct a computer or otherprogrammable data processing apparatus to function in a particularmanner, such that the instructions stored in the computer-readablemedium produce an article of manufacture including instruction meanswhich implement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer orother programmable data processing apparatus to cause a series ofoperational steps to be performed on the computer or other programmableapparatus to produce a computer implemented process such that theinstructions which execute on the computer or other programmableapparatus provide processes for implementing the functions/actsspecified in the flowchart and/or block diagram block or blocks.

Moreover, the present disclosure is not limited to the specific circuitelements described herein, nor is the present disclosure limited to thespecific sizing and classification of these elements. For example, theskilled artisan will appreciate that the circuitry described herein maybe adapted based on changes on battery sizing and chemistry or based onthe requirements of the intended back-up load to be powered.

The functions and features described herein may also be executed byvarious distributed components of a system. For example, one or moreprocessors may execute these system functions, wherein the processorsare distributed across multiple components communicating in a network.The distributed components may include one or more client and servermachines, which may share processing, as shown on FIG. 7, in addition tovarious human interface and communication devices (e.g., displaymonitors, smart phones, tablets, personal digital assistants (PDAs)).The network may be a private network, such as a LAN or WAN, or may be apublic network, such as the Internet. Input to the system may bereceived via direct user input and received remotely either in real-timeor as a batch process. Additionally, some implementations may beperformed on modules or hardware not identical to those described.Accordingly, other implementations are within the scope that may beclaimed.

In some implementations, the described herein may interface with a cloudcomputing environment 730, such as Google Cloud Platform™ to perform atleast portions of methods or algorithms detailed above. The processesassociated with the methods described herein can be executed on acomputation processor, such as the Google Compute Engine by data center734. The data center 734, for example, can also include an applicationprocessor, such as the Google App Engine, that can be used as theinterface with the systems described herein to receive data and outputcorresponding information. The cloud computing environment 730 may alsoinclude one or more databases 738 or other data storage, such as cloudstorage and a query database. In some implementations, the cloud storagedatabase 738, such as the Google Cloud Storage, may store processed andunprocessed data supplied by systems described herein. For example, theclient characteristics and/or metrics 106, model inputs 112 a, modeldata 112 b, peer characteristics and/or metrics 114, and/or peer results116 of FIG. 1A may be maintained in a database structure such as thedatabases 738. Similarly, the requestor historical selection(s) and/orpriorities 122 of FIG. 1B and/or the entity characteristics and/ormetrics 410 of FIG. 4 may be maintained in a database structure such asthe databases 738. Further, the insurance exchange system 502 of FIG. 5may maintain any of the product data 540, subscriber data 542, providerdata 544, plan data 546, model data 548, broker data 550, transactiondata 552, model input data 554, transaction metrics 556, peercorrelation data 558, peer selections data 560, client data set(s) 564,peer results 566 combined peer results 568, and peer selection metrics570 in a database structure such as the databases 738.

The systems described herein may communicate with the cloud computingenvironment 730 through a secure gateway 732. In some implementations,the secure gateway 732 includes a database querying interface, such asthe Google BigQuery platform. The data querying interface, for example,may support access by the insurance exchange system to data stored onany one of the providers 504 and the brokers 506, as well as the datarepository 512 and computer readable media 562.

The cloud computing environment 730 may include a provisioning tool 740for resource management. The provisioning tool 740 may be connected tothe computing devices of a data center 734 to facilitate the provisionof computing resources of the data center 734. The provisioning tool 740may receive a request for a computing resource via the secure gateway732 or a cloud controller 736. The provisioning tool 740 may facilitatea connection to a particular computing device of the data center 734.

A network 702 represents one or more networks, such as the Internet,connecting the cloud environment 730 to a number of client devices suchas, in some examples, a cellular telephone 710, a tablet computer 712, amobile computing device 714, and a desktop computing device 716. Thenetwork 702 can also communicate via wireless networks using a varietyof mobile network services 720 such as Wi-Fi, Bluetooth, cellularnetworks including EDGE, 3G, 4G, and 5G wireless cellular systems, orany other wireless form of communication that is known. In someexamples, the wireless network services 720 may include centralprocessors 722, servers 724, and databases 726. In some embodiments, thenetwork 702 is agnostic to local interfaces and networks associated withthe client devices to allow for integration of the local interfaces andnetworks configured to perform the processes described herein.Additionally, external devices such as the cellular telephone 710,tablet computer 712, and mobile computing device 714 may communicatewith the mobile network services 720 via a base station 756, accesspoint 754, and/or satellite 752.

It must be noted that, as used in the specification and the appendedclaims, the singular forms “a,” “an,” and “the” include plural referentsunless the context expressly dictates otherwise. That is, unlessexpressly specified otherwise, as used herein the words “a,” “an,”“the,” and the like carry the meaning of “one or more.” Additionally, itis to be understood that terms such as “left,” “right,” “top,” “bottom,”“front,” “rear,” “side,” “height,” “length,” “width,” “upper,” “lower,”“interior,” “exterior,” “inner,” “outer,” and the like that may be usedherein merely describe points of reference and do not necessarily limitembodiments of the present disclosure to any particular orientation orconfiguration. Furthermore, terms such as “first,” “second,” “third,”etc., merely identify one of a number of portions, components, steps,operations, functions, and/or points of reference as disclosed herein,and likewise do not necessarily limit embodiments of the presentdisclosure to any particular configuration or orientation.

Furthermore, the terms “approximately,” “about,” “proximate,” “minorvariation,” and similar terms generally refer to ranges that include theidentified value within a margin of 20%, 10% or preferably 5% in certainembodiments, and any values therebetween.

All of the functionalities described in connection with one embodimentare intended to be applicable to the additional embodiments describedbelow except where expressly stated or where the feature or function isincompatible with the additional embodiments. For example, where a givenfeature or function is expressly described in connection with oneembodiment but not expressly mentioned in connection with an alternativeembodiment, it should be understood that the inventors intend that thatfeature or function may be deployed, utilized or implemented inconnection with the alternative embodiment unless the feature orfunction is incompatible with the alternative embodiment.

While certain embodiments have been described, these embodiments havebeen presented by way of example only and are not intended to limit thescope of the present disclosures. Indeed, the novel methods, apparatusesand systems described herein can be embodied in a variety of otherforms; furthermore, various omissions, substitutions and changes in theform of the methods, apparatuses and systems described herein can bemade without departing from the spirit of the present disclosures. Theaccompanying claims and their equivalents are intended to cover suchforms or modifications as would fall within the scope and spirit of thepresent disclosures.

What is claimed is:
 1. A system for automatically identifying peerorganizations of a subject organization within a transactional platform,the system comprising: processing circuitry; and a non-transitorycomputer readable medium having instructions stored thereon, wherein theinstructions, when executed by the processing circuitry, cause theprocessing circuitry to: receive, via a network from a remote computingdevice of a user, a request for peer comparison with the subjectorganization; in real time responsive to receiving the request, identifya plurality of peer organizations of the subject organization, whereinidentifying the plurality of peer organizations comprises generating,from a plurality of features of the subject organization, one or moreorganization data sets representing one or more characteristic featuresand one or more transactional features of the subject organization,wherein each of the one or more organization data sets is customized tofeatures associated with a respective model of one or more modelsconfigured to detect similarities between a given organization and aplurality of other organizations, for each of the one or moreorganization data sets and each of the one or more models, apply therespective organization data set to the respective model, wherein eachof the one or more models is trained with respective training data setsincluding characteristics of the plurality of other organizations, andobtain, through application of the respective organization data set tothe respective model, the plurality of peer organizations sharing one ormore similarities with the subject organization, wherein the pluralityof peer organizations represents respective portions of results outputfrom the respective model; and prepare, for presentation at the remotecomputing device, a graphical user interface for presenting at least aportion of the plurality of peer organizations, wherein, for each peerof the plurality of peer organizations, the respective peer isrepresented along with i) at least a portion of the plurality of peerfeatures of the respective organization within the graphical userinterface and ii) a control for selecting the respective peer for use incomparison metrics.